前言

Day 2 開始前，還是先來一段跟 CVE 完全沒關係的喇賽。

昨天 Day 1 寫完後，晚上跑去看《蜘蛛人》。買的電影套票有附爆米花和飲料，原本想說可以邊看邊吃，感覺非常舒服。

我是在前面還在播預告片時才進場，走到位子上坐好，電影也剛好開始。接著吃了幾口爆米花，準備喝我的檸檬紅茶時，才發現一件很尷尬的事——我忘記拿吸管了。

偏偏影廳和櫃檯又在不同樓層。電影都開始了，實在不想為了一根吸管錯過劇情，所以那杯檸檬紅茶就這樣從頭到尾完整地放在旁邊，一口都沒喝……

最後電影看完了、爆米花吃完了，檸檬紅茶則原封不動地跟著我一起離場。

好啦，題外話先到這裡。

回到正題：大家說的 CVE 是同一個東西嗎？

昨天 Day 1 講了一大堆，其實重點只有一句：

同一個漏洞，不管研究者、廠商或資安新聞怎麼稱呼，只要寫的是同一組 CVE ID，大家就知道在講同一件事。

但到了 Day 2，麻煩又來了。

因為大家平常講「CVE」時，可能是在講三個不同的東西。

既然前面剛好聊到電影，我們就繼續拿電影票來比喻。

假設我的電影票上有一組訂單編號：

ABC-123456

這組編號可以讓櫃檯找到我的訂單，概念上就像 CVE ID。每一組 CVE ID 都是唯一的，用來指向特定的一筆漏洞紀錄。

但編號是編號，資料是資料。光看 ABC-123456，你不會知道我看哪部電影、幾點開演、坐在哪裡，也不知道套餐裡有沒有那杯完全沒喝到的檸檬紅茶。

把訂單打開後，裡面的電影名稱、場次、座位和套餐內容，就像 CVE Record。CVE ID 負責告訴大家「要找哪一筆」，CVE Record 才會告訴大家「這一筆裡面寫了什麼」。

至於影城系統裡全部的訂單集合，就可以想成 CVE List。它不是某一張電影票，而是收錄所有紀錄的總目錄。

先用三句話記起來：

• CVE ID：要找哪一筆漏洞
• CVE Record：這筆漏洞有哪些資料
• CVE List：收錄所有 CVE Record 的官方目錄

所以當有人說：

可以幫忙查一下這個 CVE 嗎？

最好再確認一下，他是想確認那組 CVE ID、查看 Record 裡的漏洞內容，還是到 CVE List 搜尋紀錄。

平常聊天時全部簡稱 CVE 當然沒關係，反正大家大概聽得懂。但真的要寫通報、查資料或設計系統時，這三個東西就不能全部混在一起。

CVE Program 自己也知道這件事，所以官方術語表直接把單獨使用的「CVE」標成 Ambiguous。講白一點就是：只說 CVE，實在有點模糊。

接下來就把 ID、Record 和 List 分開來看。

第一層：CVE ID 是唯一編號

CVE ID 的格式看起來很簡單：

CVE-YYYY-NNNN

它由三個部分組成：

• CVE：固定前綴，看到它就知道這是一組 CVE ID
• YYYY：年份
• NNNN：四位以上的序號

例如大家很熟悉的 Log4Shell：

CVE-2021-44228

看起來沒有很複雜，但裡面有兩個很容易搞錯的地方。

年份不一定是發現漏洞的年份

2021 不一定代表研究者在 2021 年發現漏洞。依 CVE Program 的說明，年份會依 CVE ID 被保留、Record 首次發布，或漏洞首次公開的時間來決定。

所以只看這四個數字，沒辦法知道漏洞是哪一天被發現、哪一天通報廠商，也不知道廠商什麼時候完成修補。想還原完整時間線，還是得去看 Record、廠商公告或研究者公開資料。

最後一段不一定只有四位數

很多人看到 CVE-YYYY-NNNN，會以為最後只能放四位數。

其實四位只是最低長度。序號可以有五位、六位，甚至更多位，而且官方沒有設定最大位數。

因此，如果系統只接受四位序號，以後遇到合法的五位或六位 CVE ID，就可能直接把人家擋在門外。

不過要注意，格式正確只代表它「長得像」CVE ID，不代表這組 ID 一定存在，也不代表漏洞資料已經公開。

就像一串文字長得很像電影訂單編號，不代表櫃檯系統裡真的找得到這筆訂單。

要確認內容和狀態，就要繼續看 CVE Record。

第二層：CVE Record 才是完整資料

CVE ID 只回答：

我們現在講的是哪一個漏洞？

CVE Record 才開始回答：

這個漏洞到底是什麼？

一筆公開的 CVE Record，至少會提供：

• CVE ID
• 簡短的漏洞描述
• 受影響的產品與版本
• 可以公開查證的參考資料

除此之外，還可能看到 CWE、CVSS、致謝資訊、修補方式，以及 CNA 或 ADP 補充的其他資料。

換回電影訂單的例子，CVE ID 就像唯一的訂單編號；CVE Record 則是打開訂單後看到的完整內容。訂單內容之後可能更新，例如更換座位或修改套餐，但原本用來識別這筆訂單的編號不需要跟著改。

CVE Record 也是一樣。描述、版本範圍或參考連結可能在公開後繼續修正，但大家仍然可以透過同一組 CVE ID 找到它。

有編號，不代表資料已經公開

CVE Record 會處於不同狀態：

RESERVED 最容易讓人誤會。

你可能已經在廠商公告、GitHub issue 或新聞裡看到一組 CVE ID，點進 CVE.org 卻只有 RESERVED，什麼產品、版本和描述都看不到。

這不代表網站壞掉，也不代表有人忘記按儲存。通常只是這組 ID 已經先拿來做漏洞協調，但負責的 CNA 還沒準備好公開完整內容。

REJECTED 也不是直接把資料刪掉。這筆紀錄仍會留在 CVE List，讓後來查詢的人知道：這組 ID 已經失效，不要再繼續使用，也不會把它重新發給另一個漏洞。

第三層：CVE List 是官方總目錄

如果 CVE ID 是訂單編號，CVE Record 是單筆訂單內容，那 CVE List 就是收錄全部訂單的總目錄。

當然，CVE List 收的不是電影票，而是由 CVE Program 識別或接收到的 CVE Record。

一般使用者可以在 CVE 官網搜尋紀錄；如果要做大量分析、資料同步或建立弱點平台，也可以從官方的 cvelistV5 repository 取得採用 CVE Record Format 5.x 的機器可讀資料。

因此，在 CVE List 中找到一組 CVE ID，只能確定官方目錄裡有這筆紀錄。至於漏洞資料是否已經公開，或這組 ID 是否仍然有效，還要繼續看它是 RESERVED、PUBLISHED 還是 REJECTED。

不能只看到搜尋結果出現，就直接腦補成「漏洞已確認、分數 9.8、修補也已經出了」。後面那些資訊都要另外確認。

把三個名詞放回真實案例

假設今天拿到：

CVE-2021-44228

這串唯一編號是 CVE ID。

打開後看到的漏洞描述、受影響產品、版本、狀態與參考連結，是這個 ID 所對應的 CVE Record。

而收錄這筆 Record，也持續收錄其他漏洞紀錄的官方目錄，就是 CVE List。

所以有人說「這個漏洞已經有 CVE」時，還可以再多問一句：

是只有 ID 已經保留，還是 Record 已經正式公開？

這句話很重要。因為只有一組編號，不代表 CVSS、CWE、修補版本或 PoC 都已經準備好了。它們可能出現在 Record 裡，也可能要到廠商公告、NVD 或研究者文章繼續找。

好啦最後還是推薦去看蜘蛛人，整體下來真的不錯看